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“Courage is resistance to fear, mastery of fear- 
not absence of fear.” 


Mark Twain 


We at ASK Magazine offer our condolences to all those who have suffered directly or indi- 
rectly because of the horrible events on September 11. Please remember we are stronger 
together than any of us alone. Keep this with you and gather courage from It. 
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IN THIS issue 


How Big Is Your Project World? 

by Todd Post 



How big is your project world? Is it big enough to contain other cultures, head- 
quarters, hierarchies, and weird harpoon-like guns? Sure it is. The great American 
poet Walt Whitman said it best, "I am large/ I contain multitudes." And so must you, 
Mr. and Ms. Project Manager. 

In this issue of ASK, we look outside the project box. See how several talented 
project managers have expanded their definition of project scope to include manag- 
ing environments outside the systems and subsystems under their care. 

Here s a sampling of what we've put together for you this issue: 

In "Three Screws Missing," Mike Skidmore tells about his adventures at the 
Plesetek Cosmodrome in northern Russia. Mike was Project Manager of the NASA 



ABOUT THE AUTHOR 


contingent on this joint sponsored research mission with the Russian Space Agency. 
A winter launch made working under stressful conditions unavoidable. Read how a 

good project manager who wants to get the job done no matter what has no choice 
but to adapt. 

Ray Morgan in his story, "Our Man in Kauai," suggests we take a broader view of 
what's meant by "the team." On Ray’s project, the Pathfinder solar-powered airplane, 
his definition of the team was not satisfactory if all this meant was the folks on salary. 
Read how Ray and his NASA sponsors worked with the native peoples in Kauai to 
achieve a high altitude world record flight, and why it might never have occurred 
without everyone working together. 

fenny Baer-Riedhart, the NASA program manager on the same Pathfinder solar- 
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powered airplane ; schools us in how to sell a program to Headquarters in "Know 
Thyself-But Don't Forget to Learn About the Customer Too." Prior to its amazing tra- 
jectory into the stratosphere, Pathfinder might never have gotten off the ground had 
Jenny been working less diligently to gain the support of Headquarters. 

Scott Cameron of Proctor and Gamble, one of our two regular Feature writers, 
talks about sharpening your hierarchical IQ in "The Project Manager and the Hour 
Glass." See how you measure up when it comes to working with your hierarchy. Learn 
from Scott s 30 years of project management experience on getting along better with 
hierarchy and thus increasing the odds of your project's success. 

Mike Jansen in The Lawn Dart describes how he and the "voodoo crew" on the 
Space Shuttle Advanced Solid Rocket Motor program borrowed a harpoon-like gun 
from the Coast Guard to catch particles inside of a plume. Why? Because they 
thought it would work. Find out if it did. How big is your project world? In this case, 
apparently, as large as your imagination will allow. 

These are just some of the stories you'll find in ASK this issue. We hope they 
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cause you to stop and reflect on your own project's relationship to the world outside. 
We are also launching a new section this issue, There are No Mistakes, Only Lessons. 
No stranger to ASK readers, Terry Little inaugurates this new section with his article 
"The Don Quixote Complex." 

Hope you find plenty of learning opportunities this issue. Let us know what you 
think. 

Todd Post 
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My Future Revisited 

by Dr. Edward Hoffman 



"And exactly what do you do for me?" asked then NASA Deputy Administrator, 
Hans Mark. 

As was his custom, Dr. Mark was hosting a winter holiday social for Cooperative 
Education Students from NASA Headquarters. Standing in a corner of the room try- 
ing to appear inconspicuous, I was feeling privileged to be one of the lucky CO-OP 
students at the home of the Deputy Administrator. 

But I nearly choked when I realized Dr. Mark was talking to me. Before I could 
say anything, he put the question in context for everyone there whose ears were now 
raised. "I know why the other students are here," he said. "They're all engineering stu- 
dents. I know what they can do for NASA, but why do I need a psychologist on staff?" 

Understand now this was almost twenty years ago. The other thirty or so people 
attending the party probably forgot the question shortly after it was asked. But for 
me it serves as a small moment of truth and remains vividly etched in my awareness 
all these years later. 

First, it indicates the degree to which a professional working in a behavioral field 
focusing on individual and team development was at one time virtually invisible at 

NASA. More important, it underscores what a dramatically different place NASA has 
become. 

In the early r98o’s, professional development at NASA more or less followed the 
traditional apprenticeship model. Valued professionals, mostly engineers and scien- 
tists, spent many years fine-tuning their skills within their selective disciplines. When 
an opportunity to manage a project came up, it normally was under the direction of 
an experienced tutor ; often more than one. 

Professional development was once a slow process, believe it or not, nourished 
by an organization of seasoned veterans. Experience was acquired over a lengthy 
duration in which the individual could experience all phases of a project. The need 
for professional development was muted and at best supplementary. 

Since then much has changed at NASA. We've gone from large projects that gen- 
erally take many years to complete to smaller ones that happen, as we all know, 
Faster, Better, and Cheaper. In keeping with this new paradigm, the apprenticeship 
approach is gone, replaced by accelerated learning programs. Myriad tools exist to 
prepare the modern project manager - web-tools, career development models, intact 
team support, benchmarking, coaching, simulation training, knowledge sharing, uni- 
versity programs, formal mentoring, e-learning, lunch symposiums, etc., etc. All of 
these came into existence to quickly prepare managers to survive in an environment 
of speed, change, and the rapid transitions that occur around the borders of chaos. Is 
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it better this way? That question is for another article. For now, let's just say it is how 
it is. 

There's little doubt when Dr. Mark asked what exactly do you do for me, he had 
no idea how NASA was going to change in the next two decades. The truth is I had 
no idea myself how different a place NASA would become in twenty years. But had 
I, and had I told all, you could bet no one in the room would have dared believe it 
could all come true. 
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From PowerPoint Slides to Powerful Stories 

by Dr. Alexander Laufer 


An experienced NASA project manager was invited to talk at a Knowledge 
Sharing (KS) meeting sponsored by the Academy of Program and Project Leadership 
(APPL). Not used to speaking about his work in front of his peers, i.e., other NASA 
project managers, our project manager did not sleep well all week prior to the meet- 
ing. His wife, who had always been a balm to him in times of stress, tried to comfort 
him by pointing out how well he'd done in his presentations in front of the directors 
at his center. This was true, he was known at the center to be a terrific front man for 
any project he worked on, but in this case it was little comfort. 

Again, his wife tried to help by assisting him with his presentation. If not an IT 
expert, she was certainly better than he was with PowerPoint, and thanks to her his 

slides looked great. "Give me a grocery list," she liked to say, "and I can make a pres- 
entation of it." 

The trouble was, and he could see it was difficult for her to understand, the best 
looking presentation m the world would not have made a difference in alleviating his 
concern about speaking in front of this group. At the meeting he would be speaking 
to other project managers, 15 in all, "the best of the best," as the meeting organizers 
like to say of the project managers they invite. 

"It’s not just the audience," he tried to explain. "There’s a difference in the kind 

of energy in the room when someone tells a story instead of using a slide presenta- 
tion." 

She looked puzzled. "But we've got PowerPoint! It's the new beta version." 

He had spent what he realized was an "unhealthy" amount of time on the pres- 
entation, preparing the slides, editing them until he could not stand looking at them 
any longer, practicing his delivery in front of his whole family, including his young 
children and even his poor dog. It’s funny because our project manager had such a 
good time participating m other KS meetings. He enjoyed listening to other project 
managers tell stories about their projects, and he never lacked for his own examples 
to bring up in his remarks to them either in the large or small group discussions. 

During the first part of the meeting, our project manager found it difficult to con- 
centrate on the other presentations. Looking around the room, he recognized the 
nametags around the horseshoe-shaped table as some of the best project managers in 
NASA. Some of them in fact were veritable superstars. 

When he took his seat at the horseshoe in the conference room, he was wishing 
he had not been so quick to accept the offer to present. When asked to talk about his 
recent project, he got excited and said yes right away. All sorts of ideas sprung to 
mind to talk about, but as he began thinking about them as a coherent narrative he 
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saw his experience as something very different from what occurs on most projects, 
hardly something common enough to spark a meaningful group discussion. To make 
matters worse, the presentation was going to concern some of the difficulties 
involved during a project, and though he had heard others talk about difficulties on 
their projects, he didn't want people to think these difficulties were all that the proj- 
ect was about. 

As he listened to his peers from other NASA centers share their experiences, the 
project manager looked across the room at another project manger from his center. 
They flew in together to the meeting and on the plane he was surprised to hear his 
colleague sound so pessimistic about the meeting, although it was clear soon enough 
that this was the colleague's first time attending a KS meeting. 

"What can anybody really get out of listening to a bunch of people tell stories!" 
his colleague grouched. "All I'm interested in is the lessons and tools. I hear they have 
a website where they publish all the stories. For my money, it would be a better use 
of everyone's time if we all just read the material on the web and sent emails to each 
other." Then he snorted. "I mean like who really wants to talk about a story." 

After grouching some more about how he wished the meeting were being held 
somewhere else, preferably where he could pack in a half a day of good skiing, the 
colleague asked him what his presentation was going to be about. When our project 
manager named the project, the colleague remarked, "Oh yeah, I heard all about that 
and the stuff you and your team had to go through to complete it on schedule. 
Amazing you ever pulled it off." 

What should have sounded like a vote of confidence, our project manager heard 



as a challenge. During those awful nights, those sleepless nights just before leaving 
for the meeting, he thought about any possible way to make the presentation more 
interesting, and as he ransacked his memory for details, little bits of humor and spe- 
cific detail about the project, he wasn't sure if anyone would be able to generalize 
from his unique experience. 

Suddenly it was time for our project manager to get up and speak. He was intro- 
duced as one of the most dynamic project managers at his center. He felt a little 
embarrassed being introduced this way but the faces in the crowd looked expectant, 
not incredulous, and this steadied him as he walked to the front of the room. 

The first part of the presentation went exactly as planned, but it felt all wrong. 
His delivery seemed wooden, it sounded too scripted, and so he decided to abandon 
the slides altogether and tell stories he had not rehearsed nor planned on sharing. As 
he told these stories, he grew more relaxed, the words came out so much easier, and 
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soon he was enjoying himself. Was it his imagination or did people look more inter- 
ested in what he was saying? 

Someone laughed at a little story he told about a unique aspect of the project, 
something he originally thought best to leave out because he didn't think anybody 
would be able to relate to it. Heads all around the room were nodding. A question was 
asked, answered. Someone told a story about something similar that happened on 
one of her projects. Now that one person other than the presenter told a story, others 
came forward with their own stories. Before long it seemed like everyone was 
involved in the dialogue. More questions were asked, answered, asked, answered...; no 
longer was it one individual presenting to a room full of listeners, but an entire group 
of people sharing their own unique stories about their projects. The magical thing 
about this was that many of the lessons were similar. 

Here is an excerpt of what transpired: 

"We realized on this project the best way to save time and money was by hold- 
ing weekly face-to-face meetings with our main contractor, and at times even more 
often." 

"I’ve got some difficulties with this. It costs a lot of time to travel back and forth. 

I tend to believe you can accomplish an awful lot by just being smarter in how you 
use email and phone conferencing." 

"Hold on now. I've got to say something about this. I’ve also found on my proj- 
ects it was the face-to-face time that made the biggest difference. This is especially 
crucial at the beginning of the project, and also any time a major contractor joined 
the team. What I ve found in cases like these is that face-to-face interaction prevent- 
ed misunderstanding from occurring and helped build trust. Sure it costs some time 
and money on my part, but without it I don't know how we would have stayed on 
schedule." 

And I ve found no matter how much time you spend composing them, emails 
always just make you aware of the tip of the iceberg. Projects don't sink because of 
the dangers you see ahead of you. It's the stuff below the surface that does the most 
damage, and by actually going out and talking to people you learn how big and dan- 
gerous those issues really are." 

Our project manager standing at the front of the room felt more like a facilitator 
than a presenter, but that was okay with him. What he was hearing sounded good, it 
sounded right, and for the first time in a week he recognized this as the feeling he 
had brought home from these meetings in the past. 

"This presentation and our dialogue illustrate an important lesson for us all," said 
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one of the project managers at the table, and lo and behold, to our project manager's 
amazement, it was the colleague whom he flew in to the meeting with from his cen- 
ter. "For me it's an especially important lesson. Why? Because I didn't have much 
faith that I could learn anything at this meeting. I don't know every detail about peo- 
ple's projects, but the thing that strikes me is that these stories have gotten me to 
think about my own project in a way I hadn't been able to before. Thinking, ponder- 
ing, reflecting, this is all great. To be perfectly honest, I don't think I've thought this 
much about my own decisions and actions since I asked my wife to marry me 20 
years ago." 

The room got very quiet. No one quite knew what to say, until the same project 
manager who made the observation stood up and rallied everyone, "Come on, let's get 
on with things. Doesn't anybody have a story to tell?" 

When our project manager who had given the presentation returned to his seat, 
the first thing he wanted to do was write down everything said during the dialogue. 
He had learned so much. But before he could do that, and no sooner had he reached 
his chair, the editor of ASK was already on top of him, imploring him to submit his 
presentation as a story for publication in ASK. Publish it in ASK--what a fabulous 
idea! ASK is sent to all the project managers in NASA. Instead of sharing his story 
with just 15 project managers, he could make it available to the entire Agency, and, 
for that matter, the entire world, ASK being on the web. 

Never before had the project manager fancied himself a writer, but the material 
was apparently good, all those people were nodding, the ASK editor was practically 
begging him; the stories about the project just seemed to come out of him so easily, 
why not write it down then? 

Four months later, he was in the office one afternoon and got a phone call. It was 
his wife and she said she had to talk with him right away to tell him that she'd read 
his story in ASK and was moved by it. "I have a much better appreciation now of 
what you were going through to finish that project on time." 

"There's something about a story that just appeals to the heart," he said. 

"I'll say," she added. "What you wrote certainly isn't like that grocery list I helped 
you prepare. I mean you took a grocery list and turned it into a real meal." 

Well, what was there to say after that? No matter whose praise came later, hear- 
ing this from his wife was like adding to the meal a bottle of fine wine. 
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From PowerPoint Slides to Powerful Stories 


Lessons 


• We need both face-to-face communication and virtual communication. 
Ambiguity is best dealt with by using face-to-face communication. This is true in proj- 
ect life and in knowledge sharing. 

• A movie is more interesting than a slide show. Likewise, a story is more inter- 
esting than a bulleted list. 

• Sharing a unique story with a group of peers will trigger other members of the 
group to share their own unique stories and will generate a productive dialogue. 

• What is common to powerful stories is their uniqueness. Among other things, 
knowledge is about applying general principles to unique situations. Therefore, 
unique stories are powerful knowledge sharing vehicles. 


U To be perfectly hon- 
est, I don’t think I've 
thought this much about 
my own decisions and 
actions since I asked 
my wife to marry me 20 
years ago. n 
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The Don Quixote Complex 

by Terry Little 


Prelude to a Mistake 
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I've made plenty of mistakes in my career, but the one that I think of as provid- 
ing the greatest learning opportunities occurred while I was program manager of a 
large Department of Defense (DoD) project designated by Congress as an acquisition 
reform program. I was told I would have my department's support to try almost any- 
thing-so long as it wasn't illegal-to improve acquisition in DoD. 

One of the things that came to me was to emulate a practice used by many com- 
mercial companies, profit sharing. I wanted to establish a way for the people work- 
ing for me to share in the savings of the program. As I saw it, it was a win-win situ- 
ation. I was sure the savings were going to be enormous, and I believed it would 
stimulate my people to be more creative, innovative, and give them a greater sense of 
ownership over the outcome of the program. I said to myself, "Self, you could look 
really heroic if you got this approved and your people got a big fat bonus all because 
of your brilliant idea." 


entered the Air Force in 1967 and 
served on active duty until 1975. 


Thus I set off on my Don Quixote quest to get approval. 



□ All I needed was to 
get approval, I believed, 
and there would be this 
big cash payment for 
the people who worked 



Despite My Best Efforts 

When I went back to tell the people in my department, I found their reaction to 
be a little too cool for my tastes. Suddenly they were backing off when I started talk- 
ing about pay-for-performance incentives. But that didn't matter to me. I already had 
fallen in love with my idea and was determined to get approval at the Pentagon no 
matter what. 

I commenced to making trips from Florida to Washington, DC every week, talk- 
ing to various people in the Pentagon, explaining what I had in mind and why it was 
such a wonderful idea. All I needed was to get approval, I believed, and there would 
be this big cash payment for the people who worked for me. 

Over the next two years I spent almost half my time in Washington. I got so car- 
ried away that my boss came up to me and told me to stop this. "This is not your job," 
he said. "You've got to get back to your program." 

I told him, albeit in a polite way, "No!" 

So carried away did I get with my brilliant idea that I decided to try and see the 
Secretary of Defense himself. The Secretary of Defense, no matter who he is, is a seri- 
ous man. Fortunately, he was also patient with me. I managed to get an appointment 
on his calendar for a 15-minute meeting. I explained my proposal. He listened, and 
then he said, "Well, I need to talk with my staff about this." 
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My stomach dropped when he said that. Finally, there was this horrible realiza- 
tion for me. All along I thought I just had to get to the right person. Here I thought I 
had him. When he said this to me, unenthusiastic as everyone else I talked with, I 
knew that I was finished. I knew this because the people he was going to talk with 
were the same people I had talked with before I got to see him. 

What I Learned as a Result 


To push the system is the right thing to do, but whenever you make a decision 
you always have to weigh the cost. I had in my mind that I was doing this for all the 
right reasons, that I was doing it because I was standing up for the people who were 
working for me, the people who worked 10 to 12 hours a day, the people who came 
in on weekends. Because they respected me and I was leading them, I felt motivated 
to keep pressing forward. But once it became about me, about my success, I lost sight 
of the fact that I was responsible for them back home in Florida, where the real work 
of the project was being done. The cost of pushing on the system, in this case, far out- 
weighed the benefits. 

What I learned derives from three big mistakes I made. 

Mistake one: I lost focus. I forgot what my job was and why I was there. The 
whole time that I was devoted to my campaign to bring profit sharing to everyone on 
my team the real work of the program unfortunately suffered, so much so that when 
we moved into the next phase it was almost terminated because of things that 
weren t done in the previous phase. The major reason for this neglect was because I 
was spending so much of my time at the Pentagon. 

Mistake two: I didn't realize it at the time, but I persisted at this for so long not 
because I was impassioned about trying to help my people. Instead, it became about 
keeping my ego from being bruised. I persisted because I couldn't admit that I had 
failed. I couldn't admit that this hill was too tough to climb. I closed my eyes to every- 
thing except my own focus and my own desire to be recognized for achieving this 
thing that nobody else had ever done. That was clearly wrong. 

Mistake three: After this was all over and I looked back and saw that it was my 
fault that the program experienced so many difficulties, I felt disgusted with myself. 

I thought constantly about what I had done, how I could be so stupid, and it took 
nearly a year for me to come to some kind of peace with myself. For a year it made 
me draw in and not want to push anymore, it made me timid and risk-averse, and 
that is a crippling state of mind to be in for a project manager. 


u To push the system 
is the right thing to do, 
but whenever you make 
a decision you always 
have to weigh the cost. 



APPL' 


The NASA ACADEMY OF PROGRAM 


AND PROJECT LEADERSHIP 


13 


TGRRY LITTLG 



u I persisted because I 
couldn't admit that I had 
failed. n 


I learned three major things from this experience. One was how important it is 
to maintain your focus no matter how attractive it might seem to go after something 
that's not quite within the focal plane. Two, how important it is to separate your ego, 
that is, your self-worth, from your job. Three, how critical it is when you do make a 
mistake--and when you are trying to do anything at all you are going to make mis- 
takes-to forgive yourself immediately and move forward. Yes, you need to forgive 
yourself immediately, not six months later, not a year: immediately. By not forgiving 
myself I was only compounding the other two mistakes. 

The irony of it all is that I did get approval to start a profit sharing program, but 
only for civilian employees. Uniform military were prohibited. Because not everyone 
could participate, we decided not to implement it. 
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The Trouble with Success 

by John Brunson 


In preparation for the February 1996 reflight of the Tethered Satellite System 
(TSS) payload, the Marshall integration and test team traveled to Kennedy Space 
Center to support the Interface Verification Test (IVT) between the satellite and teth- 
er connector. The test, which was run in the summer of 1995, proved to be hotter than 
the Florida sun and caused the team to sweat just as much. 

We were feeling the heat because TSS hardware was failing to pass the IVT. A 
great deal of our frustration was caused by the fact that this system had flown before 
and had successfully passed the same test. The Marshall and Kennedy test team, 
many of whom had been involved during the first mission, pulled together to try and 
understand the cause of this failure. 

On the surface there was no reason for this simple but critical test to be failing. 
Every precaution had been taken between missions to safely stow the hardware. 
Inspections were made prior to connecting the two halves. The same procedure suc- 
cessfully used during the first mission had been followed, and we had made no mod- 
ifications to the hardware. 

As the integration and test team lead, I had to make the call back to Marshall and 
alert the Program Manager as to our status. We were eight months away from launch 
and a solution was needed quickly to keep us on schedule. All eyes, including 
Headquarters, were focused on us identifying and correcting the problem. 

Start With the Obvious 

We were fortunate to have good people from Marshall, Kennedy, and the con- 
tractor community as members of the team. We also pulled in expert help from out- 
side as needed. You’ve got to remember that success occurs due to the "people" on the 
team and their commitment to solving "the team's" problem. Everyone on the team 
understood the urgency of the problem. 

It s hard to describe exactly the energy that comes from working on a crack team 
in a pressure situation like this. Say nothing of the fact that all the while everyone 
knew our actions were being watched throughout the Agency. We all were doing the 
best job we could anyway, but with this "little" bit of added pressure, it was an awe- 
some motivating force. Situations like this are when the true character of the indi- 
viduals and their contributions to the team surface. When you actually experience 
something like this at a crux moment in a project, it’s almost like you are operating 
in a totally new space, and you yourself are transformed, knowing that the energy 
you are getting from your teammates is bringing out the absolute best in you. 
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eyes, including 
Headquarters, were 
focused on us identify- 
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Ilia Trouble with Success 


U You’ve got to remem- 
ber that success occurs 
due to the “people" on 
the team and their com- 
mitment to solving “the 
team's” problem. n 



Onboard Space Shuttle Atlantis a crewmember used a 70mm handheld camera to capture this medium closeup 
view of early operations with the Tethered Satellite System (TSS). 


Hours were spent reviewing procedures and drawings. We considered all the 
contingencies that might be contributing to the problem. Additional testing and 
analysis was conducted and evaluated. We spent hours gathered around the confer- 
ence table, throwing ideas out and putting them up on a white board. The pros and 
cons of each one were explored, and the proponents of their theories argued vigor- 
ously why one was superior to another. 

Finally, we selected an option to implement, what came to be known as the "360 
Degrees Test," and were hopeful it would support our assumptions, verify the prob- 
lem and, if successful, lead us to correcting the problem, re-running the IVT, and ver- 
ifying our fix. 

You look for the obvious and try to work your way back. We believed the con- 
nector on the tether side was manufactured improperly and was actually cocked off 
its normal perpendicular path and recessed by several thousandths of an inch back 
into the connector body. The 360 Degrees Test allowed the team to connect, discon- 
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nect, rotate, and reconnect the bottom half in 15 degree increments. This test was 
designed to find the region around the connector that got connectivity. 

It was obvious to us when we got the data back that there was a manufacturing 
problem within the Tether Connector. The vendor acknowledged that it was a manu- 
facturer s defect. There was a great sigh of relief all around because we knew the 
problem could be fixed quite easily. X-rays and other data helped to verify this. Once 

we were satisfied with all the test results, we set off to replace the connector and ulti- 
mately passed the IVT. 



Question 


To what extent does luck 
play a role in project suc- 
cess? 


You May Never Know How Close You Come 


The moral of this story is, "The trouble with success is you may never know how 
close to failure you came." As I said at the start, this mission was a reflight. There was 
actually no change between the first time we did the integration and the second. The 


procedures we used were exactly the same. Probably the first test team got lucky and 
nailed the connection just right. 

We have known risks in every program, and we have unknown risks because it's 
the nature of the beast. The problem is our past successes drive the schedule that we 
create for reflight missions. We try to plan for the best we can, but until the vehicle 
is up in the air in an environment it was built for, doing what it is supposed to do, 

you have a lot of restless nights. Plan and hope for success, pray for luck, but be ready 
to address failure. 


Lessons 

• If results do not meet expectations, for better or worse, we have little choice but 
to see this as an opportunity for learning. 

• Teamwork is of the utmost importance during crisis situations. 
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Three Screws Missing 

by Michael Skidmore 
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To say that the Russian Space Program's (RSA) approach to space flight is dif- 
ferent than NASA's is at best an understatement. I had the opportunity to experience 
some of this difference firsthand in late December 1996 while working with our 
Russian counterparts to prepare for the launch of Bion 11. This was the ninth mis- 
sion in the COSMOS/Bion series and the first conducted under a bilateral NASA/RSA 
contract. 

This mission was different from earlier ones in that it was our first joint mission, 
whereas on prior missions we flew as invited guests. This time we had control of 50 
percent of the science payload. Earlier missions had covered a range of experimental 
models: everything from simple cell cultures to non-human primates. The purpose of 
this current mission was to study the physiological effects of flight on two 4-5 kg. 
male rhesus monkeys. 

NASA's role, in addition to specific scientific research goals, was to develop the 
bioinstrumentation and to work with our Russian counterparts to ensure that it was 
fully functional when integrated into the spacecraft. A striking indication that this 
was a different world from anything I'd experienced at NASA occurred when we got 
to the Plesetsk Cosmodrome in northern Russia where the launch took place. 

It was December and the conditions in northern Russia during winter are obvi- 
ously quite cold. Even so, this was an exceptional time. All of northern Europe was in 
the grip of a fierce winter storm, so the temperatures outside were especially harsh 
and the snow quite deep. On one occasion, while returning to the base late in the 
evening, the snow was falling so heavily we couldn't see more than a few feet in front 
of the bus, and snowdrifts on the road were piled up as high as the hood. That the 
driver could see the road, could keep the bus on the road, and got us safely back to 
our quarters struck me as a small miracle. 

What was also remarkable about this episode was that none of our Russian coun- 
terparts seemed to regard the bus ride as anything out of the ordinary. Understand 
correctly, in no way am I trying to suggest their attitudes were cavalier. What is 
"remarkable," I think, is how their composure reflected the "get-the-j ob-done" culture 
of the Russian Space Program. Blizzards, sub-zero temperatures, hazardous road con- 
ditions, these were certainly obstacles to overcome, but did they ever weaken any- 
one's resolve? You never heard so much as a complaint. 

We saw this kind of stoic resolve throughout the project. One of the most impres- 
sive examples was when they had to deal with assembly and integration procedures 
to mount a top cover to one of their enclosures. The Russians found out they were 
short three screws so someone on their team found a box of parts, dumped them out, 
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fished through them until they found three screws that fit, and we were back in busi- 
ness. At NASA you can visualize a more "resource intensive" environment where the 
screws would arrive in certified containers with a specific screw for each position and 
mounds of paperwork verifying each part's heritage back to the quarry. 



u What is “remark- 
able,” I think, is how 
their composure reflect- 
ed the “get-the-job-done” 
culture of the Russian 
Space Program. fl 


The setting of the Bion 11 Project. 


Despite our cultural and work-related differences, we worked effectively with our 
Russian counterparts. Why? I would say the main reason was that together we 
approached the project as a unified team in the strongest sense of the word, meaning 
we shared the same goal of bringing off a successful mission. The two sub-teams were 
able to function as one united and effective team, overcoming the natural obstacles 
of an advanced technological endeavor. The key to this was collocation. 

The bond and trust we established by working together, as well as suffering 
together, cannot be overstated. It was a tremendous improvement to be able to talk 
directly with them as a problem arose. For instance, on the night of the launch there 


tn 


[The bond and trust 
we established by work- 
ing together, as well as 
suffering together, can- 
not be overstated... 


appeared to be a technical glitch and we were called down to the launch facility from 
the hotel where we were staying. At first the Russians suspected it was an issue with 
our hardware. We could look at the equipment, discuss it with them, and we were 
able to establish categorically that it was not our hardware to everyone's satisfaction. 
Could we have achieved this as quickly and pleasantly as we did via distance? I will 
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When is paperwork an 
indication of an orderly 
process, and when is it a 
reflection of mistrust? 


venture an opinion that our collocation under these austere conditions went a long 
way to warm their ears to what we said. 

While we had some differences of opinion along the way, in part because there 
were fundamental differences in our approaches, overall the mission was a success. 
It was quite an education for me, working within the Russian system and seeing how 
differently they address and resolve problems. The take-away lesson for me was the 
realization that you can arrive at success in many different ways. The Russian proce- 
dures, while much less paper intensive and seemingly more accepting of risk than the 
US methods, have been quite successful. The modified Soyuz rocket and 
Cosmos/Bion spacecraft have a success ratio in the range of 98%. While I wouldn't 
go so far as to embrace their methods, there is certainly something we can learn from 
their experience and attitude that limited resources are a challenge, not a showstop- 
per. 


Lessons 

• There is always more than one way to complete a project on time and on cost. 

• Collocation helps to overcome cultural differences between individual members 
and provides the entire team with a unified sense of purpose. 
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Know Thyself-- But Don't Forget to Learn 
About the Customer Too by Jenny Baer-Riedhart 



Crash and Learn 

I made several appearances at NASA Headquarters (HQ) to brief higher-ups on 
the status of my program when I was the program manager of a Joint Sponsored 
Research Alliance (JSRA). Early on in this endeavor, I learned a key lesson in work- 
ing with multiple customers. Always know the folks you're meeting with, and always 
tailor what you're going to say based on who you know will be there. 

I learned this the hard way, I m afraid to say, after getting thrown out of people' s 
offices. What can I say, I m a slow learner. I wasn't quite as attuned to the personali- 
ties in the room as I should have been, what their requirements were, what their 
problems might be with what I was saying; I failed to realize that I was basically per- 
ceived as a threat, a bringer of very bad tidings. 

"Hey we've got this great program back in California," I said, and from the word 
go they were hammering me. They didn't want to hear anything about a program 
aimed at developing Unmanned Aerial Vehicle (UAV) technology. 

"This is not going to work! This is not the kind of airplane we want! Why are you 
telling us about this!" 

From their standpoint, I was the enemy, someone who would suck up resources 
they needed in other areas. 

I should have seen it ahead of time. The thing is I did see it, but I thought all I 
had to do was show up and explain how successful the program was and voila, they 
were in my pocket. Yes, I knew how they were fighting for their other platforms, how 
they had their own constraints and clients whom they had to please, but I believed 
m my heart that this program was important for NASA and that I could convince 
them of it. 
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What I failed to recognize was that people are not convinced just because the 
seller believes she has a wonderful product. The seller needs to understand what the 
buyer wants from a product. 

Staying Alive 


You cultivate supporters at HQ by putting yourself in other people's shoes and 
learning what do they want to get out of this. In my case, I imagined that I was on 
the other side of the table and I ve got a tight budget and I'm looking at having to cut 
programs. "Tell me why should we keep you alive?" they're going to ask. I think, 


u I failed to realize that 
I was basically per- 
ceived as a threat, a 
bringer of very bad tid- 
ings. ri 


What would I want to hear if I was in that position?' I would want to make sure I 
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had a viable program, a program that I could get recognition for, one I could get con- 
gressional backing for; it should be successful, and it might as well be unique too. 
Even better, it should NOT have to cost a lot of money. 

And that, basically, was how I packaged it. 


HI 


You cultivate sup- 
porters at HQ by putting 
yourself in other peo- 
ple’s shoes and learning 
what do they want to 
get out of this. n 



Pathfinder in flight over lakebed. 


But before I went anywhere near HQ again, I did some serious training. I got in 
shape. You might even say I went to boot camp. 

Mainly I found people who appeared regularly at HQ to talk about their pro- 
grams and used them as a sounding board. We set up role-playing sessions, or what 
we endearingly referred to as our "murder boards." Folks from my Center and other 
partners in the JSRA pretended to be my audience back at HQ. We didn't just pick 
people arbitrarily, we looked for ones with areas of expertise similar to those we knew 
I would interface with at HQ. I briefed them with the charts I was going to take, they 
told me what I’d be killed on, and I changed what I had to in order to stay alive. When 
I went back to HQ, it still didn't feel like I was among friends, but at least nobody 
kicked me out of his office. 

"Here's my understanding of where you guys need to be, the missions you need 
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to be looking at, the platforms you want to support." 

Basically, I just figured out what mattered most to them. The information I gath- 
ered straight out of their reports. I said to them this is what you guys want, and this 
is how I can deliver. 


"This airplane is going to provide you with sensors that are better than any of the 
ones you've currently got. These sensors you'll be able to use on the platforms you're 
already flying and at a much lower cost." 

I brought charts that were worth more to my program than an original Picasso. 
Talk about visual aids, I had one with 40 pictures showing all the things we were 
doing and how they were interrelated. It was eye watering. They were blown away. 

The rest of course, is history. Years after the events described here, the program's 
legacy demonstrates our work to sell UAVs at HQ was well worth the effort. Helios 
soared this summer to world altitude records, and reached the thinnest edges of 
Earth's atmosphere. There is even talk now that someday a craft based on this design 
is going to be used to study the atmosphere on Mars. By then, I expect, no one will 
ever recall our early battles to prove we had a winning project from the start. 


EL Question 

How do you work to dis- 
cover what your customer 
wants and needs? 


Lessons 

• There are times when the role of the project leader is simply to sell the project. 

• Projects can, and do, succeed because of politics. And they fail because of poli- 
tics as well. Politics does not have to be a dirty word. If it means working closely and 
openly with customers and stakeholders, it is an essential approach that requires con- 
tinuous dedication of time and attention. 

The most compelling sales pitch you can make is not that you have something 
wonderful to sell. It is 'I understand what you need.' 
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Our Man in Kauai 

by Ray Morgan 
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Before we went to Hawaii to begin flight tests on the Pathfinder solar-powered 
airplane, we knew we needed the support of the local community there. Otherwise it 
was going to be a struggle to achieve any of our goals. 

We'd chosen the island of Kauai because of the favorable conditions there for 
high altitude flight tests and also for the opportunity to perform demonstration sci- 
ence missions over areas that were uniquely undisturbed by humans. But to take 
advantage of these conditions; we had to overcome obstacles that were far more 
down to earth. 

For one thing; no one had ever gotten permission to fly an Unmanned Aerial 
Vehicle (UAV) in FAA airspace there beyond the site of the operator. While we could 
conduct our high altitude test flights without leaving the airspace controlled by the 
Navy to perform the science missions planned over the island we needed to operate 
in FAA controlled airspace. 

In a place like Kauai, where the locals are faced with a combination of a high cost 
of living and few jobs at the professional level, coupled with a highly desirable envi- 
ronment that prompts many to want to find a way to live and work there, there is a 
natural apprehension about outsiders. In spite of a natural desire to be as helpful as 
possible, there is a sense of past exploitation, and it is important to be sure that an 
inappropriate (if unintended) impression isn't made. It helps to find someone who 
can serve as your entree into the community. In that way, Dave Nekomoto was our 
man in Kauai. 

Dave is a fourth generation Japanese-American, born and raised in Hawaii. He 
was a former Executive Officer at the Navy base where we were conducting the flight 
tests. Like a lot of the Kauaians we met, Dave had more than one job. Primarily, he 
was the manager for the local branch of a support contractor on the base. In addition, 
he worked with the Kauai Economic Development Board in trying to bring more tech- 
nology-based jobs to Kauai. He also worked as the Director of Operations and heli- 
copter pilot for a local land owner, Mr. Bruce Robinson, whose family is a longtime 
sugar cane producer in Kauai. The Robinson family owns a third of the island of 
Kauai. Dave flies helicopter tours over the Hawaiian Island of Niihau, which is owned 
by Keith and Bruce Robinson. This private island, Niihau, was determined to be one 
of only a few options where our fragile aircraft could make a contingency landing on 
terra firma, making the difference between recovery and loss of the unique aircraft if 
an emergency landing had to be made. One thing Dave did for us was smooth the way 
with Mr. Robinson so that we could land on Niihau if we needed. 
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Dave also was our "ace" chase pilot, flying a videographer/photographer to docu- 
ment the flights with air-to-air shots near the islands. More importantly, Dave intro- 
duced us to the unique culture of Kauai and the Pacific Missile Range Facility (PMRF) 
where we operated, and helped us "fit in" and establish a good rapport with the local 
community. 

Dave did favors like this because he liked us and considered this type of support 
part of his job(s). That was the main ingredient we found in any business dealings we 
did on Kauai. It was a culture where your personality always took you further than 
the size of your billfold. With Dave we endeared ourselves to him right away because 
among other things, we devoured all the tasty food he and his friends Vince and 
Johnny cooked for us in their giant (and I mean GIANT) woks, and sang with him. 
Yes that's right, we sang. 

Dave had-how shall we say-a thing for karaoke. Anybody who was tight with 
Dave spent time with him at his house singing. This was Dave's way of relaxing at 
the end of the day, and he had quite an elaborate set up at his place for it. 
Microphones, speakers, and acoustics any garage band would kill for..., plus, he must 
have owned every song ever recorded. The lyrics flashed across a television screen, so 
all you had to do was punch a button on a computer and there was the song, sans 
vocals of course. It was up to you to fill them in, and heaven help you if you were 
bashful. 

No one on the Pathfinder team had a Sinatra voice, but we managed to get every- 
one to sing something. Even those who were painfully shy managed a few lines of 
"Happy Birthday." It was all in good fun, and more importantly it showed we had the 
right stuff, in that we weren't afraid to risk embarrassment and that we all trusted 
each other with our most important possession, our egos. 

One could not possibly overstate the importance of these karaoke nights at 
Dave s in terms of their bearing on the success of our project. Dave invited many 
folks from the base that we worked with each day. Also, the whole NASA and 
AeroVironment team was there, along with spouses, children, and other friends that 
had come over for a visit. It brought the team together and it made friends with our 
Hawaiian and military hosts. Without Dave's karaoke parties we probably still would 
have eventually ingratiated ourselves with the community, but developing a social 
relationship certainly broke the ice and formed a basis of trust. 

From Dave we learned things about Kauaian culture that we didn't know before- 
hand, for instance, the utmost regard Kauaians have for those who educate their chil- 
dren. Hence, in planning our marketing strategy on the island-yes, we had a market- 
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u One could not possi- 
bly overstate the impor- 
tance of these karaoke 
nights at Dave’s in 
terms of their bearing 
on the success of our 
project. n 


u We came to Kauai 
not knowing exactly how 
the human dimension 
would figure into our 
activities, but we knew 
whatever way it worked 
itself out was going to 
be critical to our suc- 
cess. n 


ing strategy, don't you have one for your project?-we developed educational pro- 
grams in the schools and put together displays at the local museum. We. ourselves 
helped to write the lesson plans and NASA Public Affairs Education Outreach pro- 
fessionals led training workshops for the teachers to show them what we were doing 
so that they could share this with the kids. The Kauai Community College sponsored 
a solar powered racecar which was a jewel in their crown of technical achievements. 
We involved the community college by hiring students to work for us at PMRF, 
exposing them to advanced solar technology by being part of our team. This was done 
on Dave's advice and he put us in direct touch with the right people at the college-it 
helped that his brother in law is the Dean of Instruction there. Working with the base 
commander and public affairs office, the NASA and AV team orchestrated an open 
house that brought in approximately 1000 local schoolchildren to see the Pathfinder, 
its payloads, and key parts of the PMRF support equipment. We jokingly called this 
event the "1000 Kid March," and the name sort of stuck. It was tremendously suc- 
cessful and students and teachers from across the state participated in this memo- 
rable event. 

The community, to put it immodestly, fell head over heels in love with us. "This 
is a good thing," people were saying. "These people are doing something special." That 
kind of talk has a way of making things happen. Dave was quick to let Hawaii's polit- 
ical machine know what was going on with our project at PMRF, which resulted in 
Hawaii's entire congressional delegation sending a letter to NASA commending us on 
the success of our program. Suddenly money that hadn't been available before 
appeared and this gave the project some extra lift, so to speak, making our attempts 
at a world record altitude flight a viable goal. Also, people on the island that worked 
at places we stayed, places we ate, and the airline and car rental agencies all got to 
know many of the team. When we had to make travel arrangements that were sub- 
ject to change with events in our flight schedules, this relationship proved very 
important. 

By the time we left, every Kauaian knew about Pathfinder and what we were try- 
ing to accomplish--and, more importantly, they were behind us a hundred percent. To 
vouchsafe this, we made sure that they felt like Pathfinder was as much their project 
as it was ours. Everyone on the island was welcome to come out and see the airplane. 
In busloads they did. When we broke the world record, we held a flight celebration 
and invited all of our hosts and PMRF support personnel to join us at one of the parks 
near the base. We provided all the food and entertainment. It was a bash. 
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None of us can do 
much by ourselves, it is 
only with the help of oth- 
ers that we do great 
things. 


Pathfinder airplane in flight over Hawaii. 

Indeed, nothing paid off more for us than cultivating friendships in the commu- 
nity. A small example of this is the day after the big celebration. When we got to the 
base the next morning and discovered a problem with our phone system, within ten 
minutes someone was there and it was fixed. A bigger example of course is we got 
the permission we sought to fly outside FAA airspace. We managed to accomplish 
this with less red tape than what we were required to go through at our home base 
in California. 
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I'm sure the cynics will look at this and say all we were doing was wooing the 
community to get what we wanted. For those inclined to see the world this way you 
can bet they make little distinction between a friend and an asset. The way I see it, 
we had friends on the island; if they were assets too, that's beside the point. We 
enjoyed sharing our accomplishments with everyone who wanted to be part of the 
team. The world record was all of ours. 

Many times in our projects we think that just being smarter than someone else 
or having the best idea is all we need. That helps, no doubt, but you've got to under- 
stand the human side of things. We came to Kauai not knowing exactly how the 
human dimension would figure into our activities, but we knew whatever way it 
worked itself out was going to be critical to our success. That's why we set aside 
money in our budget specifically for the kinds of activities described here. Call it mar- 
keting, but by the time we left Kauai, we were probably spending up to 20 percent of 
the project time on it. 

Bottom line, people are the most important part of any operation. None of us can 
do much by ourselves, it is only with the help of others that we do great things. It is 
important we recognize our interdependence in any enterprise, and the earlier we do 
it, the easier things are, and the better they work. 

Certainly, a lot of factors contributed to our success in the skies above Kauai. No 
doubt one very important factor is that the people of Kauai felt invested in our suc- 
cess and wanted to do whatever they could to help us reach our goals. Whatever 
advancements derive from our work on Pathfinder, the support of the Kauaians who 
helped make it possible must never be forgotten. And, our man in Kauai, Dave 
Nekomoto, was our guide in finding that support, walking us through blessings, cel- 


Would you please share an 
example in which you sang 


ebrations, traditions, culture, sharing with us his local contacts and "mana'o", the 
Hawaiian word for wisdom. 


karaoke (figuratively) to the 

benefit of your project? Lessons 

• Cultural differences can impact the success of a project and it behooves the 

Project Manager to learn how best to work with unique cultures. 

• Soft is hard. All sorts of "crazy ways" of cooperation affect project success. 

• When in Rome, behave like the Romans. Adjust to the demands of the local cul- 
ture even if it means singing karaoke. 
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The Lawn Dart 

by Michael Jansen 


The Voodoo Crew 

It wasn't too long after I agreed to be the Thermal Integration Manager for the 
Space Shuttle Advanced Solid Rocket Motor (ASRM) program that I gained an appre- 
ciation for why the thermal community was always viewed by the Shuttle Program 
Office as a group of "out-there" voodoo practitioners. 

Because it was ; well ; true. 

Despite a technical background that included aerothermodynamics, I was still 
surprised by the degree (no pun intended) to which cutting edge predictions of 
Shuttle ascent aerodynamic and plume heating depended on educated guesses and 
extremely murky empirical formulae. My new team ; comprised of highly seasoned 
experts from two NASA Centers and a half-dozen contractor companies, apparently 
based its products on equations laden with fudge-factors, the values of which were 
argued strenuously at each meeting of the governing Thermal Panel-which I now 
chaired. To each prediction, a margin of safety was attached, the magnitude of which 
also depended on the much-argued consensus of the Thermal Panel. With this being 
the state of the art, no wonder our craft was viewed by outsiders as black magic. 

One of the major components of ascent heating, the radiation produced by the 
Shuttle's two solid rocket booster plumes, was known to depend on the size and dis- 
tribution of individual aluminum-bearing particles throughout each plume. 
Estimates of this crucial variable were crude at best, and were based on extrapola- 
tions of data collected from firings of much smaller motors with different propellant 
mixtures than that of the ASRM. As a result of this uncertainty, the factor of safety 
applied to radiation predictions was typically on the order of 100%. Such large uncer- 
tainty margins presented a significant impact to the design of the Shuttle launch 
vehicle's thermal protection system, as well as to the vehicle's ascent profile. The 
effect on the Shuttle system's payload-to-orbit capacity was not good. 

But how to improve the accuracy of the prediction? Conventional means of col- 
lecting particles would have required a significant test equipment design effort; even 
if we could piggyback on already-planned tests, we'd have to design and build instru- 
mented test stands able to withstand the harsh plume environments. And we had no 
budget for such an endeavor. 

Fortunately we had our share of out-of-the-box thinkers on our voodoo team, and 
the thought du jour was... Lawn Dart! 
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The Lawn Dart 


U Once the lawn dart 
team learned to shoot 
straight, we were set 
for a test with a real 
plume as target. i 



QM-6 test firing at Wasatch Operations, Morton Thiokol, Utah. 



Seeds of Our Magic 

One of the analysts had spent his early -career with the Coast Guard, and was 
familiar with the harpoon-like guns used to hurl hawsers from Coast Guard ships to 
other boats to allow the two vessels to be lashed together for boarding. He assumed, 
and was correct, that such surplus equipment could be acquired via inter-agency req- 
uisition. His boss, a member of our Thermal Panel, proposed to me that he get a cou- 
ple of these guns and have one of his co-operative education students design a parti- 
cle-catching projectile for them to hurl through the plume. The scheme quickly drew 
the moniker "lawn dart." 

Several upcoming subscale solid rocket motor tests would provide excellent 
opportunity to test and fine-tune the system and collect preliminary data. The major 
payoff would come later, if we could collect particles from the plumes of two full-scale 
test firings. The guns were free, the co-op needed a meaningful project to work on, 
and this organization's discretionary budget could handle the minor materials costs 
associated with fabricating whatever lawn dart design the co-op came up with. 

Vital data at no cost to the program? How could I say no? 

The co-op proved to be especially inventive, and devised a blunted aluminum dart, 
the bulbous head of which was covered with double-sided tape. The time to transit the 
plume was calculated short enough not to allow the contraption to melt. We secured the 
use of an electron microscope to allow an admittedly arduous counting of particles of 
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various sizes per unit area of tape. The machine shop quickly produced several speci- 
mens, and the initial non-plume test firings initiated by remote control were successful. 

Once the lawn dart team learned to shoot straight, we were set for a test with a 
real plume as target. 


The first subscale motor test firing of the lawn dart was nearly its last. The motor 
sat in its vertical test stand with the exhaust end pointed skyward. Once the motor 
was fired and its plume was well established, the lawn dart team did its thing, where- 
upon the dart was promptly carried several hundreds of feet into the air with the 
plume, only to fall back to strike the test stand. Suddenly, the test director wasn't so 
sure he wanted to let our bunch near his equipment. After much cajoling, and once 
we reduced the dart's fin surface area, he gave us the OK for a second attempt. This 
one sent the dart through the plume, but not without another surprise: an unantici- 
pated, plume-assisted journey several hundred yards out the other side-which 
required a determined search to find the darn thing. Nonetheless, the team was jubi- 
lant. The darts were surviving their journeys with only minor scorching, and the 
materials lab analysis showed we were indeed capturing excellent particle samples! 
After a second refinement of the dart s design, the lawn dart crew was ready for the 
full-scale motor tests. 

As it turned out, the crew did an expert job; the darts launched during the two 
critical tests flew beautifully, intersected the plumes at the points of interest, and col- 
lected particle samples that allowed the analysis team to develop a repeatable parti- 
cle size distribution model. Along with the concurrent radiometer measurements our 
team took, and the factoring in of some computational fluid dynamics predictions of 
the plume flow's structure, the particle data allowed us to refine our radiation mod- 
els to the point that the prediction uncertainty level could be reduced from 100% to 
10-15%. This represented a major leap forward in the state of the art, all made possi- 
ble by some out-of-the-box thinking. 

Gotta love that voodoo engineering! 


H Question 

How often do project man- 
agers use “alternative” 
resources to solve technical 
problems? 


Lessons 

• In a problem-solving situation, all ideas (no matter how "out-there") should be 
considered. 

• We shouldn't be so focused within our professional specialties that we forget 
we are the sum total of our life-experiences; the solution to a work-related problem 
may well lie within the memory of some totally non-work-related experience. 


This is Michael C. Jansen's third 
story to appear in ASK. Like Mike's 
writing? Read his other two sto- 
ries, Natural Relationship and 
Garage-Style Engineering, in previ- 
ous issues. 
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The Hour Glass and the Project Manager- 

Part 2: Improving your Hierarchical IQ by w. Scott Cameron 
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In Part 1 of this article, I asked you to think of the Project Manager's (PM's) job 
in terms of an hourglass. In this analogy, the top of the hourglass is the PM’s hierar- 
chy, the bottom the project team, and the connecting tube the PM. The hourglass sand 
can be anything from proposals, directions, data, and other forms of articulated com- 
munication to the unstated forms of communication like assumptions, perceptions, 
and/or prejudices that pass between the two parts. A PM's success is often deter- 
mined by his or her ability to effectively manage this passage of sand! 

In Part 1 , 1 focused mainly on the PM's role in managing the project team. Here 
I will consider the other end of the glass, the hierarchy. I base much of what I know 
on my own observations. You have probably noted that little is written or taught 
about how PMs should manage their hierarchy. The "Dilbert" cartoon strip may even 
be the most widely cited authority on this subject. My experience derives primarily 
from an opportunity I once had to report directly to a manager four levels above me 
and to assist in managing his project teams and his hierarchy for two years. This, per- 
haps, could be the most insightful experience of my career. I learned what was impor- 
tant to five separate levels in my organization! 

What PMs Say About Their Hierarchies 

The comments I hear from PMs regarding their hierarchies generally tend 
toward varying states of bewilderment: 


"They want me to manage everything and don't want to be disturbed." 


"They've done this before.. .they should know how tough it is!!" 


"They can't handle the truth!" 


"They can't make up their minds and its hurting my project" 

"They're busy and don't have time to spend with me." 

"My hierarchy wants to meet with me regularly to follow my project's progress." 
"They know what needs to be done, why don't they just do it?" 

Hierarchy was totally aligned to my project 6 months ago. What could have changed?" 
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Things to Keep in Mind 

Some things PMs must realize about hierarchy: 

• Hierarchy is comprised of individuals, each with his or her own biases, assump- 
tions, experiences, expectations, concerns, and knowledge about the project, the proj- 
ect team, and the PM. When a PM lumps all these individuals together, "they" become 
much harder to manage than any one individual. 


Hierarchy is comprised of levels. The individual needs and expectations of one 
level toward the PM may be at odds with those at other levels. A PM needs to under- 
stand what the needs and expectations are at each level and determine a strategy to 
address them. 

• Not all hierarchy has decision-making rights on a project. A PM has to be able 
to understand and differentiate what each level can accomplish. 

• Hierarchy has information about future events that can impact the PMs proj- 
ect. The PM must gain the hierarchy's trust and confidence to obtain this information 
as soon as possible to properly manage the project team. 

Your Hierarchical IQ 

I believe PMs should take the following steps to measure and then improve their 
hierarchical IQ: 


U You have probably 
noted that little is writ- 
ten or taught about how 
PMs should manage 
their hierarchy. 


Understand your authority on the project and what items require decisions 
from outside the project team. 

Learn, early in the project s life, about all organizations whose hierarchy may 
impact your project. 

• Learn the name and level of the individuals in the hierarchy you plan to main- 
tain a communication link with. Understand what decisions pertinent to your proj- 
ect each level is able to make. 

Hold regular meetings (group or 1:1) with specific members of the hierarchy to 
better understand each one's needs and expectations throughout the life of the proj- 
ect. 


Bring the hierarchy together on a regular basis to review the project. Too often 
the PM assumes the hierarchy discusses the project and the PM s concerns with one 
another. This is not always a safe assumption. 

If you don t understand who your hierarchy is and how they can impact your 
project, you don't have a very high hierarchical IQ! 
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Communicating With Hierarchy 


Once you take the above steps, you need to improve on the following two areas 
to better influence your hierarchy and increase your hierarchical IQ. 

1. Sharpen your listening skills. Surprisingly, few PMs really listen to what their 
hierarchies are trying to tell them. If you ever wanted to be that infamous fly on the 
wall, remember that flies aren't known for being big talkers. PMs want to communi- 
cate their thoughts, ideas, plans, etc. to the hierarchy. This is good and expected of 
you, but the key is to listen to what the hierarchy is telling you about your project. 
Learn what could positively or negatively impact it, and then act accordingly. 

2. Sharpen your proposal making skills. PMs should be very clear what they want 
the hierarchy to do. Don't allow hierarchy to try and guess what you want from them. 
If you want them to do something, you should have the conviction to ask for it. If you 
don't want them to do anything, you should state this clearly. PMs should understand 
what they want of their hierarchy prior to meeting with them either in group settings 
or in 1:1 meetings. 

This wraps up my thoughts on the Hour Glass and the Project Manager. Now it's 
time to go out and practice what you've learned. Hurry now, as the sand is always 
flowing in your hourglass. 
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The Art of Scheduling 

by Terry Little 


Most managers I know think that constructing a schedule is primarily a techni- 
cal activity. I have found over the years that creating a realistic schedule for a com- 
plex project is mostly an art-one requiring lots of intuition, judgment and guesswork. 
I don't profess to know all there is to know about scheduling, but I have a few 
thoughts that might be useful. 

First, "the system" will measure a project's success by how closely it meets the 
original schedule. This is true regardless of how thoughtful, complete, or realistic the 
schedule. You would think then a wise manager would develop a schedule that pro- 
vides some slack for uncertainty, risks and inefficiencies. Guess what, this is often 
more difficult than it would seem. 

Typically, the project manager is under enormous pressure to be optimistic about 
the schedule. The pressure can stem from a variety of things: higher management 
(i.e., by way of mandated schedules or reduced cycle time imperatives), fiscal con- 
straints, contractor promises, or simply from the need to "sell" the project. It's easy, 
albeit wrong, to succumb to these pressures and come up with an optimistic, "success- 
oriented" schedule as a starting point or baseline. The project manager must resist 
these pressures and write a schedule that is relatively conservative. I have found that 
viewing the schedule as a personal commitment or a contract, as opposed to merely 
an estimate, serves as a bulwark against the pressure to adhere to someone else's 
notion of what the schedule should be. 

Second, the amount of work needed to complete a project will always expand to 
fill the time allotted to the project. This is especially true when engineers are 
involved. This seems to argue against a conservative schedule, but here I must dis- 
tinguish between the "public" schedule and the "work-to" schedule. 

The schedule I described above is the public schedule-the one that the project 
manager commits to on paper. The actual schedule that the team works toward 
should be more challenging than that-one that requires stretching, innovation and 
some luck to achieve. We have to be careful not to stretch too much, of course, and 
must remain focused on what we can realistically accomplish. But very often when 
the team challenges itself this way the project finishes earlier than the public sched- 
ule mandates. Having two schedules may complicate things, but I have found the 
benefits far outweigh the problems. 

Third, I have found that you cannot separate how long work will take from who 
is doing the work. This seems obvious, but seldom finds its way into scheduling. 
Many project managers approach scheduling by considering technical risks, work 
scope and complexity, yet they ignore execution risk. Some persons, teams and/or 
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Just as it is unrea- 
sonable to expect a 
draft horse to compete 
in the Kentucky Derby, 
so too is it unreason- 
able to expect a plodder 
to meet an ambitious 
schedule. 
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I have found it useful 
— and this doesn't come 
easy to me— to create a 
very bureaucratic 
process for changing 
requirements. 


companies work quickly while others are more methodical, plodding or mistake- 
prone. Just as it is unreasonable to expect a draft horse to compete in the Kentucky 
Derby, so too is it unreasonable to expect a plodder to meet an ambitious schedule. 
Because of this, I use the past performance of whoever is involved on the project as 
a major factor in putting together a schedule. This is what I consider as the execution 
risk, and why I am uneasy relying on so-called independent schedule estimates that 
ignore who is doing the work. 

Finally, one of the major reasons for schedule slippages is uncontrolled require- 
ments growth. In some cases, requirements growth is a fact of life. The manager may 
have to just accept growth, but, other things being equal, added work should equal a 
longer schedule. Too often I see managers who willingly agree to adding work with- 
out either increasing the time or money to do the work. In effect, this makes adding 
requirements seem "free." It is bad business and can turn a realistic schedule into 
wishful thinking. 

I have found it useful-and this doesn't come easy to me--to create a very bureau- 
cratic process for changing requirements. Basically, I say there will be no changes in 
requirements until (1) decision makers understand the cost and schedule implica- 
tions of the change, and (2) decision makers explicitly agree to those implications. It 
is quite amazing to see how a process that simply establishes accountability for 
requirements growth promotes better discipline and yields more realistic schedules. 

Many project managers succeed or fail depending on how well they deal with 
scheduling. The champion or master project manager understands that creating a 
realistic schedule is one of the most crucial challenges he or she will face. 
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Refining Procedures: Calling All Stakeholders 

by Ray Morgan 


Background 

For the longest time, we were not procedures oriented at AeroVironment. One 
guy at the top typically wrote flight procedures, and often that guy would leave out a 
whole bunch of stuff because, after all, he's just one guy... there were things he did- 
n't think about. 

Another problem that stemmed from having just one guy write the procedures 
was that not everyone used the same nomenclature. The guy who writes a procedure 
gets used to calling something by a nickname and that's how he identifies it in the 
procedure. But if other people who have to use the procedure aren't familiar with that 
nomenclature, you can imagine their frustration in trying to understand what the 
author of the procedure is talking about, not to mention the potential for disaster that 
exists because of this. 

But the most significant problem we found with autocratically handing down 
procedures was that people were far less likely to follow procedures that they neither 
created nor could change. Procedures are tools. Like tools, they need to be sharpened 
and honed. Any good craftsman wants to sharpen his (her) own tools. What's more, 
people feel less stress when they can control how they perform their tasks. 

When developing small, quick-and-dirty prototypes, it is often most economical 
to just fly it" and see what kind of problems there are. Sloppiness is intolerable when 
you work with expensive and essentially irreplaceable sophisticated airplanes like the 
unmanned, solar-powered vehicles that we specialized in at AeroVironment. With 
unmanned airplanes, what the pilot does is just a tiny fraction of what the airplane 
is trying to do. To fix a problem, you usually need to get a grasp of an entire system. 
If you've got a bunch of people who understand parts of the system, you bring them 
together to make intelligent decisions using each of their areas of expertise. 

Hence, we realized a couple of common sense things to help refine our methods 
of writing procedures: (1) one person is not as smart as a group, and (2) a person at 
the top may not understand things the same way as does someone looking at it from 
a different perspective, such as a technician who is actually performing the task. 
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Creating the Procedures 

Our first rule was always to "put the person closest to the problem closest to the 
solution. Whenever possible, the person(s) who actually performs the task creates 
the procedure for it. Providing this type of ownership is invaluable. It is also the most 
efficient way to create the procedure. Certainly, we had people cross-check their pro- 
cedures with co-workers, but we recognized that we had to provide a way with han- 
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dling the inevitable mistakes. This process of continuous improvement by the 
"owner" of the procedure accelerated the rate of development of the procedure, and 
allowed us to both rapidly refine a procedure and also allow for a quick response to 
changes in the system during the flight test program. 

Refining the Procedures 

1. We read through the procedure with a group of people who are involved. We 
also invite other people who are not directly involved with the procedure to provide 
some objectivity. We'll get a bunch of changes from that-that's generally where we 
catch the inconsistencies in nomenclature. On the next iteration the labeling is usu- 
ally very close to being error free. 

2. We then get everyone together for another read through. This time we have 
the actual hardware in front of us, and we'll practice just as we would as if we were 
going through a flight-a prototype of sorts. This time we catch, for example, that the 
pilot has turned the damping switch off before he started another test that required 
the damping switch to be on. The guy who owns that process--it may be the pilot, it 
may be a stability and control engineer-will take note of that and be responsible for 
correcting the current version of the procedure. 

3. The next time we will sit at the ground control stations-we have a stationary 
one and a mobile one (that follows the aircraft during takeoff and landing). We'll go 
through the whole process again with the same people, using the latest rewrite. This 
is the last run-through before the actual flight. 

4. After the flight, we get a group together to look at whether there were any abnor- 
malities that could be attributed to a procedure or discuss any "red-marked" changes to 
a procedure made during the flight. The person who is the owner of a procedure cap- 
tures any issues that came up and corrects the procedure before the next practice. 

Tips 

This process allowed us to come up with a procedure that everyone understood 
and could follow to the letter. You must see it as a continuous improvement process. 
With a group of people working together you can probably turn out a perfect proce- 
dure in no more than 2 to 3 iterations, depending on how complicated a procedure it 
is of course. Another benefit is that more people feel ownership for the procedure. 
Not every project may require such a rigorous approach for developing procedures as 
we used at AeroVironment for developing flight procedures, but certainly all projects 
benefit from this sort of attention to detail. 
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Example: Surf/Beach/Shallow water crash of Aircraft 
Symptom: 

• Aircraft crashes in or near surf. Aircraft is close enough to shore that it could 
migrate onto beach with wind and wave action. 

• Aircraft crashes on sand, but is exposed to surf spray that wets surface. 

Rules: 

If Aircraft crashes in deep water, the aircraft will be allowed to sink, or scuttled, 
and not recovered. 

If Aircraft crashes in the surf, where it is evident it will be moved on shore by 
the winds and currents, it must be recovered. 

SHOCK HAZARD (120VDC) 

• It is possible to receive a lethal shock from the aircraft whenever it is in the sun- 
light, if surfaces/components have been exposed to salt water. The solar array will 
continue to produce power in the daylight, and the saltwater could provide conduc- 
tion of lethal voltages and currents in an unpredictable fashion. Unless fuses are 
blown, Li batteries also provide shock hazard, even at night. 

Pilot Tasks 

1. Turn all motor switches off. 

2. Contact Aircraft Pilot if airborne and request visual assessment of crash site 
and relay to Mission Director. 

Engineer Tasks 

1. Provide GPS location to Mission Director 

Mobile 1 Tasks 

i. Drive Mobile GCS to within visual range of Aircraft, if near runway, to get best 
signal path from Mobile l to Aircraft, and allow Mission Director to assess situation. 

Mission Director Tasks 

l. Proceed with MISHAP PLAN 

General Comments: 
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ASK talks with Jerry Madden 



ASK: How do you like being a reviewer? Does it feel like you're on the other side 
of the fence ; so to speak? 

Madden: Unfortunately you get the same feeling. At least I do. You feel respon- 
sible for the mistakes that are made. That's what you're there for ; to make sure these 
people don't make any mistakes. You hope when you go to a meeting you find noth- 
ing, that things are fine. But that doesn't happen too often. 


Jerry Madden retired from NASA 
in 1995 as Associate Director of 
Flight Projects at Goddard Space 
Flight Center. During his distin- 
guished 37-year career, he was 
considered by many of his peers to 
be one of NASA's "premiere" 

Project Managers. Outside the 
Agency, Jerry is widely recognized- 
-and often quoted --for his "100 
Lessons Learned for Project 
Managers," a collection of mostly 
serious, sometimes funny (128 
actually) observations about proj- 
ect management that he compiled 
over the years. 

Since his retirement, Jerry has 
remained active by serving on sev- 
eral NASA review boards, by work- 
ing part time at the Smithsonian 
Institution's Air and Space 
Museum, and by sharing his 
wealth of knowledge about project 
management with anyone who has 
a mind to tap his abundant gen- 
erosity and frankness. 


ASK: What advice would you give a young project manager at NASA today? Let's 
say someone who has just been assigned his first project. 

Madden: The first thing I tell them to think about when putting together their 
team is look at who you have available to you and what are their backgrounds. Once 
you've put together a good working team and explained to them how you are going 
to run the show, the next thing you've got to do is get a cursory knowledge of what 
you re going to be doing. Learn the basics of the project. If you're going to fly a sci- 
entific mission, the least you've got to do is go out and learn about the science that's 
going to be done. Get a couple of general books. Don't try and get too detailed an 
understanding because you'll never be able to catch up if you aren't already knowl- 
edgeable in the subject. Read so that you understand the nomenclature and to get a 
grasp of the basic principles. One thing that a manager has to know is the nomen- 
clature and what it means. When I first started in this business, I was a mathemati- 
cian and was working on telemetry data. I didn't know anything about telemetry, so 
I went down to Radio Shack and got a simple book on telemetry. When an engineer 
came in and started spouting off about this stuff, he couldn't believe that I knew what 
he was talking about. It's very painful to listen to a presentation of supposed facts 
and you don't even understand the language. I've been to meetings where somebody 
gets up to explain something using the language that goes with that trade and all of 
a sudden you'll notice eyes glass over because they've lost it. You can't afford to be 
one of those glassy eyed guys if you're the project manager. You've got to understand 
what people are saying. 

ASK: What's the greatest difference between the world of a NASA project man- 
ager today and when Jerry Madden was a NASA project manager? 
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talks 


Madden: Project management itself hasn't changed. What has changed is that the 
systems have gotten so much more complicated. In the old days, you could hold the 
whole spacecraft in your mind. Now you can't hold one subsystem in your mind. In 
the early days, the people who were building the hardware knew what they were 
building, knew all its functions, and if someone gave them a piece to build that was- 
n t right they'd know it. Now they don't. It's too complicated. 


ASK: What should a project manager be doing then in this sort of environment? 


Madden: You still go out and get the best people you can. You give them the 
authority to do their job. You give them the most resources and money you can. For 
instance, you get a systems engineer who understands his main job is the require- 
ments and interfaces. To me a failure today-and it was a failure before, and it will 
probably always be a failure-is that you don't have someone interfacing with the peo- 
ple who are actually doing the work. You have to have someone on your project that 
understands manufacturing and building hardware and can talk with the technicians 
who are putting it together and find out if they are having any problems. The same 
is true with the software. Someone has to understand how the stuff is organized. One 
program I was reviewing we looked at the software and everything was going along 
fine, but something didn't feel right and we could never put our finger on what it was 
until it blew up. If someone had gone down to the people who were doing the pro- 
gramming and putting the subroutines together, you would have found out that these 
people were concerned and worried, but they had to get the work out, and they were 
getting it out, right on schedule-it's just that the work didn't WORK. 

ASK: If you were a project manager at NASA today, what would you be doing dif- 
ferently than 15 or 20 years ago? 

Madden: Paperwork. I'd be doing lot's more of it. Managers today have so much 
damn paperwork to do. They spend maybe 40 percent of their time, if they spend that 
much, managing the actual work they think they're managing. The paperwork has 
multiplied in every direction. 


U In the old days, you 
could hold the whole 
spacecraft in your mind. 


ASK: Paperwork I suppose is a byproduct of the complexity, but is it possible to 
manage a project today without all that paper? 
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INTERVIEW : JERRY MADDEN 


ASK talks with Jerry Madden 


II With the early space- 
craft there were definite- 
ly things you could do 
that you couldn't get 
away with today. ri 


Madden: Oh no, you need all that paperwork just to identify everything that's 
going on. You also need to have a risk management plan. We used to laugh when the 
first risk management reports appeared. If a project manager didn't know the risks 
he was facing, he shouldn't be building anything. Now much of the risk is buried in 
the details and is hard to evaluate from the top so a good analysis of risk has to be 
done. 

ASK: Were you a risk taker? 

Madden: Of course I was. A project manager has to be. More importantly, though, 
you've got be able to learn from your mistakes. Some of the risks I took in the early 
days were foolish, but I learned. One time I had a weight problem and threw out the 
inertial dampers. When it came around to another program and we had a weight 
problem again, one of my men came to me and said, "Are you going to get rid of the 
dampers again?" and I told him, "No because I only need to make an ass of myself 
once." That's the truth; once was all I needed. 


ASK: Was it easier to be a risk taker in those days? 

Madden: With the early spacecraft there were definitely things you could do that 
you couldn't get away with today. That's because they weren't as expensive as they 
are today. The more money that is at stake, generally the less risk you could take. In 
the old days, we used to have a saying, 'The freight train leaves.' The scientists knew 
exactly what we meant by that. If you don't make the flight on time, we're not wait- 
ing for you. On a mission where there were 15 or 1 6 scientific instruments, we would- 
n't give a second thought to flying without one. We'd fly without two. We used to say 
we'd put a lead brick on board to cover the weight. On the present space craft all the 
instruments are so damn expensive you don't lift off without one of them. 

ASK : What do you think about the Faster, Better, Cheaper culture? 

Madden: The Faster, Better, Cheaper culture is fine, but if you're doing something 
Faster, Better, Cheaper it has to meet those criteria. A small satellite in the $100 mil- 
lion range you can do Faster, Better, Cheaper, but everyone has got to understand 
you're taking a risk. You can't do something extremely complicated Faster and Better. 
You can do it maybe Better, but you can't do it Faster and Cheaper too. It takes a cer- 
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tain amount of time. You also have to have extremely good people on the Faster, 
Better, Cheaper project-better than you have on the bigger projects. To do something 
Faster, you normally have to cut corners. To do it Cheaper, you cut some of the man- 
power. You've got to make sure you are cutting the right manpower. 

ASK: In your 'Too Lessons Learned for Project Managers," you said it's not the big 
things that do a project in, it's the little. 

Madden: You rarely get clobbered by the esoteric things. If you go and look at 
most of NASA's failures, it's usually something small that someone overlooked. The 
one that got me was a very simple power supply. We had flown over 60 of these. The 
people putting it together were brand new, so why not give them something simple. 
They were easy to build and therefore it was supposed to be a mundane task. We 
ended up losing the spacecraft because a screw was too long and it shorted the power 
supply. On another spacecraft, the screw was too short. A screw for one of the mod- 
ules was holding on by less than a thread. Nobody looked at it. We were lucky that 
time. The point is, it’s not unusual for that kind of thing to happen. 



If you go and look 
at most of NASA's fail- 
ures, it's usually some- 
thing small that some- 
one overlooked. 


ASK: When 


you selected your people for a project, what criteria did you use? 


Madden: I wanted people who would take charge. Someone who would say this 
is my piece of the puzzle and wanted to manage it. I would give my people the great- 
est leeway I could. There were only a few things they couldn't do, and they knew 
what those were. Other than that, whatever decisions were made in that area were 
made by them. I didn't micromanage. I think anyone who tries to micromanage 
today is a fool. There's too much detail. Somebody has to be very familiar with what's 
going on in great depth, and the project manager can not do that. He has to count on 
his people to do it for him. 

ASK : Would you suggest that the project manager handpick every individual on 
the project? 

Madden: Normally I would let the people in charge of areas of the project make 
their own choices. But the project manager should try and know everyone. It also 
doesn't hurt to know the people not on your project. I remember one time we were 
in deep trouble and needed help so we asked the Center to give us some backup sup- 
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port. We gave them a list of 12 people who could fill our needs. None of the names 
we asked for was available; so they offered us a couple of others. We didn't take any- 
body they offered because we knew we would have been worse off than with nobody. 

ASK: Do you think that management itself has evolved over the course of your 
career and in recent years? 

Madden: I think the basic management principles are the same ; but the tools are 
better. The computer gives you a lot of different methods of looking at what is going 
on. The ability to have your data laid out in nice graphs and charts so that you can 
visualize where you're at ; that's certainly nice to have. Provided the data is accurate. 
That's something that's always worried me. I've seen too many beautiful plots and 
charts where the data underneath crumbled if you touched it. I think the computer 
really helps the modern-day manager if he uses it correctly but the first thing is you 
have to be able to trust the data. 


U I've seen too many 
beautiful plots and 
charts where the data 
underneath crumbled if 
you touched it. T 


ASK: Is there any single characteristic that you've recognized among the superi- 
or project managers? 

Madden: The best project managers are the ones who pick the right people to 
manage the day-to-day work of the project. In some ways ; he's fundamentally noth- 
ing more than that ; someone who picks good people. 

ASK: How do you learn to do that? 


Madden: By working with people. If you're not a people person, you really 
shouldn't be a project manager. There are good ones who aren't, but for some odd rea- 
son that no one can account for they still manage to get the right people to work for 
them. 


ASK: Is that the only talent you feel is worth noting? 
Madden: Yes. Because people are what make a project. 
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The following comments we received regarding Dr. Edward Hoffman's column 
"From the Director's Desk" in ASK Volume 4. We're always delighted to hear from our 
readers, and in this case it's especially pleasing as we learn that the ASK audience 
reaches all the way to the Land Down Under. 

Dr. Hoffman wrote: 

"The starting point seems to be acknowledging the new nature of working with 
others - understanding who WE are - and then moving from there to form a great team." 

In response , Adam Pearson wrote: 

I like that - recognize the situation/problem first then deal with it. I work as a con- 
sultant project manager - that is to say that I work in a large consulting organization, 
80% of whose work is as a project manager on behalf of a client. We work mainly in 
the construction industry. The company is Bovis Lend Lease - you can find us at 
www.bovislendlease.com. I work in the consulting arm of the organization. My col- 
leagues and I are always the 10% (actually maybe the 1%!) that must work to create a 
team for a construction project. We start with helping our client with project definition, 
then move on from there, appointing design consultants and contractors as we go. 

For a number of years, I have been working on the theme of "creating effective 
teams". A couple of insights, if I may be presumptuous (Ed, you probably already 
know all this): 

The team must embrace a common set of objectives - a set of objectives that each 
member of the team can wholeheartedly adopt. As you say, this must cross inter-orga- 
nizational boundaries. The second vital component is that the team holds a shared set 
of values. These values must pertain to the product of the project - a building, a rail- 
way, a NASA project.... whatever - AND must include personal, behavioral values. 

If the team really and truly commits itself to a shared set of objectives and a com- 
mon set of values, then the groundwork is set for success. There are many aspects of 
teamwork to nurture along the way but the test for success is the quality of commu- 
nications and relationships - a project's success is directly proportional to these. 

I would love to write more on this topic but wanted simply to convey to you my 
experience in the importance of objectives, values, communications and relation- 
ships. I'll be delighted to answer any queries you have. 

With thanks for the magazine and regards from Brisbane, Australia 


YOU CRN CL0S6 THG LOOP 
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ASK Magazine is 

always glad to share useful knowl- 
edge provided by our readers. If 
you've got a book review or some 
other information that you think 
will be helpful to project and pro- 
gram managers, the Loop section 
is your vehicle for making that 
information public. We invite all 
readers to contribute. 


Adam Pearson 
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a This issue we also have reviews of two books we think you'll find interesting. 

ASK Managing Editor Michelle Collins reviews All Hat and No Cattle: Shaking Up the 
System & Making a Difference at Work, by Chris Turner, who was the keynote speak- 
er at the 2001 NASA Masters Forum of Program and Project Managers. The other 
book is Out of Control: The New Biology of Machines, Social Systems and the Economic 
World, by Kevin Kelly. Jerry Mulenberg, who has been so helpful the last three issues 
reviewing books for us, is in great form once again. Out of Control is a big book and 
Jerry s review is commensurate with it for his thoroughness and insight. 


» 


Dr. Michelle Collins is 

the Managing Editor of ASK 
Magazine. She is currently on a 
one-year detail to NASA 
Headquarters from Kennedy Space 
Center where for the past five 
years she has conducted research 
on air pollution control technology. 
She also is responsible for the 
Knowledge Sharing Initiative with- 
in NASA's Academy of Program & 
Project Leadership. 


All Hat and No Cattle: Shaking up the System & Making a Difference at Work , Chris 
Turner. (1999) Perseus, MA: Cambridge. 

Reviewed by Michelle Collins, NASA Headquarters 

This book is about recognizing what's really causing the "All Talk and No Walk" 
behavior in organizations, and identifying discreet ways that you can "nudge" 
changes in that behavior. At first, it may seem a little radical, but if you can suspend 
that feeling, you may find that Turner will stretch your mind in all sorts of interest- 
ing and positive ways. She talks about things you can do now. I like that! I find it's 
too easy to think that "there’s nothing I can do - if management doesn't change, then 
nothing will change." 


There are three main issues covered in the book: 1) changing a system by nudg- 
ing the system, not by trying to drive the change, 2) creating a love-based environ- 
ment, and 3) recognizing that people are everything (conversely, good leadership is 
essential, and people will gravitate to the true leaders). Turner references an eclectic 
group of thinkers including Mark Twain, Buddha, Peter Senge, and John Seely Brown, 
and she integrates their philosophies with her own based upon her experiences at 
Xerox. 

Turner tackles most of the key issues that have been a source of frustration in the 
work environment in recent years. She talks about Performance Appraisals, 
Communications, Meetings, Training Courses, and the organizational fads of the year 
such as Quality Circles and ISO certification. Granted, efforts such as ISO 
Certification have the potential for high merit; however, the actual implementation 
of it has left most organizations operationally mired in employee ennui due to their 
frustrations with the way it was implemented. She tackles all of these issues head on 
and provides potential replies or actions that can be implemented immediately. 
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Organizations, agencies, and companies of every size, but most especially the 
behemoths, have been inflicting major new programs upon the workers at an alarm- 
ing rate. They have consistently failed, and many employees have "disengaged." Why 
is that? Turner believes it is because the sponsors of change fail to understand what 
it really takes to implement change, and because they don't respect the people work- 
ing for them. Change is a part of life and people are okay with it. There are natural 
and effective ways to implement the changes needed for an organization to survive 
the future, Turner argues. It boils down to one fundamental truth: "Companies aren't 
machines, they’re living systems...If there is a disjoint between what the bigwigs say 
and what they do, then what you immediately get is cynicism." 

Like Chris Argyris in his book Flawed Advice and the Management Trap, Turner 
focuses on the serious gap between the espoused theory and the theory in use. She 
says, this gap "is the biggest reason that people disbelieve 99 percent of organiza- 
tional propaganda... It is the reason that folks don't buy in to efforts aimed at change. 
The idea that people resist change is hokum. Humans are designed for changes. It's 
the way we survive. People resist having change done to them. They resist idiocies 
that will disappear shortly to be replaced by the latest flavor of the month. People 
resist inane organizational programs because people are smart." 

Turner suggests that the best way to make changes is for the individual to 
"nudge" the system rather than ramming full-scale changes ; one on top of another, to 
no successful end. Imagine trying to move a herd of elephants (the behemoth organ- 
ization) to a new and better grazing area. The management team hollers the 
announcement, gives a few minutes for questions, but doesn't have time to listen 
because they already have a plan they're sure will work. Ready, set, go - guns ablaze, 
a stampede starts, people are injured, and the elephants move, but in the wrong direc- 
tion. Turner proposes a more incremental approach. A little pressure on one elephant, 
it moves a little, the herd makes a slight adjustment and they all settle down. Another 
nudge, the same reaction. With patience, the entire herd can be successfully moved 
to the desired location and without people being injured. 

A great manager once told me people want to do good work, they're usually just 
waiting to be given the opportunity. Turner echoes this same concept and asks, "What 
if we assumed that most folks come to work because they want to do a good job, to 
contribute in a meaningful way, to learn, and to grow?" She suggests that if we create 
a trustful environment at work, employees will gain self-confidence, become more 
responsible, and accept accountability for what they do. She calls for creating a "love- 
based" system, where fear is no longer holding us back from realizing our true poten- 
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tial. She bluntly states, "The appraisal is just another way of instilling fear in folks, of 
keeping the power structure in place." Turner gently reminds us "people only have 
power over you if you give it to them." She states her experience is that 99 percent of 
the time when you trust the people you work with, they will continually exceed all 
expectations. People who feel good, do good." 

Turner outlines approaches that can be used throughout organizations and ways 
that each person can shake up the system. She says, her book "is written for all of you 
who want to kick up dust because you can no longer stand things the way they are." 
Although there are any number of books and articles written on complexity theory 
and the idea that organizations are natural, self-organizing systems, Turner says, "The 
machine mind-set is firmly in place. She calls this the all-hat-and-no-cattle mindset. 
And it s hurting us in every way. She believes that fundamental change does not hap- 
pen through official programs, but rather it happens moment to moment - in every 
minute of every day. 

Reviewer Note: I implemented several of the author's suggestions recently with great 
success! 

Ratings: ★ ★ ★ ★ ★ 

Usefulness to Job: ★★★★☆ 
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Out Of Control, Kevin Kelly. (1994) Perseus, MA: Cambridge. 
Reviewed by ferry Mulenberg, Ames Research Center 


If you want to challenge your thinking, this book will do it! The author says, "This 
book is based on my astonishment that nature and machines work at all.. .and was 
written to explain my amazement to the reader. The scientists and projects reported 
[in the book] have been concerned with harnessing the laws of design so that order 
can emerge from chaos, so that organized complexity can be kept from unraveling 
into unorganized complications, and so that something can be made from nothing." 
He ends the book with the question: "How do you make something from nothing?" 
and provides the answer with "The Nine Laws of God." These laws, he claims, are the 
"broadest, crispest, and most representative generalities" as organizing principles for 
complex systems. 

Among the unique qualities of the book are the intellectual challenges of under- 
standing complex, distributed, networked systems. These challenges relate to the flex- 
ibility inherent in the sustaining self-organization, control, change, learning, adapta- 
tion, and stability of these systems. Using this context, the author examines both 
man-made and what he calls "being" systems (a hive of bees, school of fish, flock of 
birds or bats) that have only a few rules to govern their group behavior-don' t bump 
into each other, keep up with your neighbors, and don't stray too far away. He says, 
it is as if "an invisible hand governs" their actions. 

He uses evolution as a model of organized incremental change in complex sys- 
tems-the kind of change that happens in decentralized systems that can learn and 
therefore adapt. One important concept he discusses is the need for control in sys- 
tems going through organized change. This type of control, he says, is similar to the 
control used in herding sheep: "When we herd a flock of sheep, we know we are not 
in complete authority, yet neither are we without control." The need is for the system 
to retain a level of control to make at least some of its own decisions in order to, "learn 
from [its] experiences... how to do the right thing." 

So what does this book have to do with NASA project management? Actually, 
quite a lot. It provides provocative ways for project managers to view how they 
approach their projects. It relates to how to think about and what to create as a proj- 
ect, and also how to behave as a project team. As complex systems themselves, proj- 
ects need to self-organize into natural "chunks" that self-govern themselves as they 
change, learn, and adapt. Thought-provoking ideas presented in the book apply 
directly to NASA projects that often, due to their complexity, border on being out of 
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control However, the author points out that being nearly out of control is not neces- 
sarily bad but is an inherent characteristic of complex systems. Heeding the Nine 
Laws of God given below will challenge the way you manage projects. 

THE NINE LAWS OF GOD 

1. Distribute being: 

"When the sum of the parts can add up to more than the parts, then that extra 
being (that something from nothing) is distributed among the parts." It doesn't seem 
like much of a stretch to say that really great projects contain more of that extra being 
than just a good project, and poor projects probably have lesser amounts of it. 

2. Control from the bottom up: 

"When everything is connected to every thing... every thing happens at once... [and] 
fast moving problems simply route around any central authority. [In this situation] 
governance must arise from the most humble interdependent acts done locally in 
parallel... [and] control must rest at the bottom within simplicity. In a rank hierarchy, 
information and authority travel one way, from top down. In a ...web hierarchy, infor- 
mation and authority travel from the bottom up, and from side to side... the chunking 
of control must be done incrementally from the bottom." In project-talk, those who 
find the problems must fix them. If they don't-or if they can't, but do not raise them 
to a higher level--a project can quickly go out of control. 

3. Cultivate increasing returns: 

"Each time you use an idea, a language, or a skill you strengthen it, reinforce it, and 
make it more likely to be used again.. .Success breeds success. Confidence breeds confi- 
dence. Order generates more order. Cooperation can emerge from self-interest." 
Increasing returns are the product of positive reinforcement within the system (proj- 
ect). Similarly, negative reinforcement makes unproductive attempts die and disappear. 

4. Grow by chunking: 

"The only way to make a complex system that works is to begin with a simple 
system that works. Complexity is created, then, by assembling it incrementally from 
simple modules that can operate independently." The underlying theme is that the 
world is full of complex, adaptive systems that learn as they evolve, and also "co- 
evolve" with other systems. In projects, if the simple modules work well, what remains 
is to ensure that the integrated "whole" made up of these modules works well also. 

5. Maximize the fringes: 

"Diversity favors remote borders, the outskirts, hidden corners, moments of chaos, 
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and isolated clusters. A healthy fringe speeds adaptation, increases resilience, and is 
almost always the source of innovations." Some of the most innovative ideas come 
from the project fringes. The difficult-to-deal-with anomalies that appear there force 
creative innovation. Although projects begin with well-defined plans, anomalies do 
appear, and only later through "retro-recognition" awareness of the anomalies begins. 

6. Honor your errors: 

"...The process of going outside the conventional method.. .is indistinguishable 
from error. Even the most brilliant act of human genius. ..is an act of trial and error. 
Error, whether random or deliberate, must become an integral part of any process of 
creation." The most fascinating project management stories are those that involve 
finding major errors that marshaled the team’s talents to overcome them. And, more 
likely than not, to correct the error required going outside "conventional methods" to 
find some innovation, or by challenging the status quo. 

7. Pursue no optima; have multiple goals: 

"Rather than strive for optimization of any singular function, a large system can 
only survive by satisficing' making good enough ) a multitude of functions. In com- 
plex projects, everything is subservient to the greater project goal. The project man- 
ager must ensure that optimization of subsystems doesn t happen at the expense of 
the overall system. If that goal is not achieved, nothing else matters. 

8. Seek persistent disequilibrium: 

"A good creation, like good jazz, must balance [a] stable formula with frequent 
out-of-kilter notes. ...Something [results from] persistent disequilibrium-a continuous 
state of surfing forever on the edge between never stopping but never falling. The 
author uses an interesting term, "pop," to describe the sudden eco-system stabiliza- 
tion in a saltwater fish tank, to describe what happens in organizations and teams 
when they suddenly begin working together as a creative organism (team). Perhaps 
after "popping," complex NASA projects should operate in a persistent state of dise- 
quilibrium to help prevent holes (at least large ones) from appearing in the whole of 
the fabric of a project. 

9. Change changes itself: 

"To get the most out of nothing, you need to have self-changing rules...If the rules 
of the game are composed from the bottom up...interacting forces at the bottom level 
will alter the rules of the game as it progresses. ..[and] the rules for change get changed 
themselves." Most project managers understand the need to be flexible, but have a 
few "inviolate rules." They also understand that there are times when even those few 
rules must change to adapt to unusual situations. 
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